SherbyNet - /page/wikibook/entry.mu

Micron Document

<!DOCTYPE html>

<title>Real-Time Object-Oriented Modeling</title>

</head>

<span id="openzim-page-title" class="mw-page-title-main"><span class="mw-page-title-main">Real-Time Object-Oriented Modeling</span></span>

</h1>

</header>

<div id="mw-content-text" class="mw-body-content mw-content-ltr" lang="en" dir="ltr"><div class="mw-content-ltr mw-parser-output" lang="en" dir="ltr"><p><b>Real-Time Object-Oriented Modeling</b> (<b>ROOM</b>) is a <a href="Domain-specific_language" title="Domain-specific language">domain-specific language</a>.

</p><p>ROOM was developed in the early 1990s for modeling <a href="Real-time_system" class="mw-redirect" title="Real-time system">real-time systems</a>.<sup id="cite_ref-room-book-summary_1-0" class="reference"><a href="#cite_note-room-book-summary-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup> The initial focus was on <a href="Telecommunication" class="mw-redirect" title="Telecommunication">telecommunications</a>, even though ROOM can be applied to any event-driven real-time system.

</p><p>ROOM was supported by <a href="ObjecTime_Developer" title="ObjecTime Developer">ObjecTime Developer</a> (commercial) and is now implemented by the official <a href="List_of_Eclipse_projects" title="List of Eclipse projects">Eclipse project</a> <a href="ETrice" title="ETrice">eTrice</a><sup id="cite_ref-2" class="reference"><a href="#cite_note-2"><span class="cite-bracket">[</span>2<span class="cite-bracket">]</span></a></sup>

</p><p>When <a href="Unified_Modeling_Language#UML_2" title="Unified Modeling Language">UML2</a> was defined (version 2 of <a href="Unified_Modeling_Language" title="Unified Modeling Language">UML</a> with real time extensions), many elements of ROOM were adopted.

</p>

<div class="mw-heading mw-heading2"><h2 id="Concepts_and_key_notions_of_ROOM">Concepts and key notions of ROOM</h2></div>

<p>ROOM is a modeling language for the definition of software systems. It allows the complete <a href="Automatic_programming" title="Automatic programming">code generation</a> for the whole system from the model. ROOM comes with a textual as well as with a graphical notation.

Typically the generated code is accompanied with manually written code, e.g. for graphical user interfaces (<a href="GUI" class="mw-redirect" title="GUI">GUI</a>).

The code is compiled and linked against a runtime library which provides base classes and basic services (e.g. messaging).

</p><p>ROOM describes a software system along three dimensions: structure, behavior and inheritance. The following sections will explain these three aspects in more detail.

</p>

<div class="mw-heading mw-heading3"><h3 id="Structure">Structure</h3></div>

<p>The structural view in ROOM is composed of <i>actors</i> or <i>capsules</i>. Actors can communicate with each other using <i>ports</i>. Those ports are connected by <i>bindings</i>. Actors do <a href="Message_passing" title="Message passing">exchange messages</a> <a href="Asynchronous_communication" title="Asynchronous communication">asynchronously</a> via ports and bindings. To each port a unique <i>protocol</i> is assigned. A protocol in ROOM defines a set of outgoing and a set of incoming messages. Ports can be connected with a binding if they belong to the same protocol and are conjugate to each other. That means that one port is sending the outgoing messages of the protocol and receiving the incoming ones. This port is called the <i>regular</i> port. Its peer port, the <i>conjugated</i> port, receives the outgoing messages and sends the incoming ones of the protocol. In other words, a port is the combination of a <i>required</i> and a <i>provided interface</i> in a <i>role</i> (since one and the same protocol can be used by several ports of an actor).

</p>

<p>An actor can contain other actors (as a <a href="Object_composition" title="Object composition">composition</a>). In ROOM these are called <i>actor references</i> or <i>actor refs</i> for short. This allows to create structural hierarchies of arbitrary depth.

</p><p>The actor's ports can be part of its interface (visible from the exterior) or part of its structure (used by itself) or both. Ports that are part of the interface only are called <i>relay ports</i>. They are directly connected to a port of a sub actor (they are delegating to the sub actor). Ports that are part of the structure only are called <i>internal end ports</i>. Ports that belong to both, structure and interface, are called <i>external end ports</i>.

</p>

<div class="mw-heading mw-heading3"><h3 id="Behavior">Behavior</h3></div>

<p>Each actor in ROOM has a behavior which is defined by means of a hierarchical <a href="Finite-state_machine" title="Finite-state machine">finite-state machine</a>, or just state machine for short. A state machine is a <a href="Directed_graph" title="Directed graph">directed graph</a> consisting of nodes called <i>states</i> and edges called <i>transitions</i>. State transitions are triggered by incoming messages from an internal or external end port. In this context the messages sometimes are also called <i>events</i> or <i>signals</i>. If a transition specifies a certain <i>trigger</i> then it is said to <i>fire</i> if the state machine is in the source state of the transition and a message of the type specified by the trigger arrives. Afterwards the state is changed to the target state of the transition.

</p>

<p>During the state change certain pieces of code are executed. The programmer (or modeler) can attach them to the states and transitions. In ROOM this code is written in the so called <i>detail level language</i>, usually the target language of the code generation. A state can have <i>entry code</i> and <i>exit code</i>. During a state change first the exit code of the source state is executed. Then the <i>action code</i> of the firing transition is executed and finally the entry code of the target state. A typical part of those codes is the sending of messages through ports of the actor.

</p><p>State machines in ROOM also have a graphical notation similar to the <a href="UML_state_machine" title="UML state machine">UML state charts</a>. An example is shown in the diagram in this section.

</p><p>A state machine can also have a hierarchy in the sense that states can have sub state machines. Similar to the structure this can be extended to arbitrary depth. For details of the semantics of hierarchical state machines we refer to the original book.<sup id="cite_ref-3" class="reference"><a href="#cite_note-3"><span class="cite-bracket">[</span>3<span class="cite-bracket">]</span></a></sup>

</p><p>An important concept in the context of state machines is the execution model of <i>run-to-completion</i>. That means that an actor is processing a message completely before it accepts the next message. Since the run-to-completion semantics is guaranteed by the execution environment, the programmer/modeler doesn't have to deal with classical thread synchronization. And this despite the fact that typical ROOM systems are highly concurrent because of the asynchronous communication. And maybe its worth to stress that the asynchronous nature of ROOM systems is not by accident but reflects the inherent asynchronicity of e.g. the machine being controlled by the software. Definitely this requires another mind set than the one that is needed for functional programming of synchronous systems.

But after a short while of getting accustomed it will be evident that asynchronously communicating state machines are perfectly suited for control software.

</p>

<div class="mw-heading mw-heading3"><h3 id="Inheritance">Inheritance</h3></div>

<p>Like other <a href="Object-oriented_programming" title="Object-oriented programming">object-oriented programming languages</a> ROOM uses the concept of <a href="Class_(computer_programming)" title="Class (computer programming)">classes</a>. Actors are classes which can be instantiated as <a href="Object-oriented_programming" title="Object-oriented programming">objects</a> several times in the system. Of course each instance of an actor class tracks its own state and can communicate with other instances of the same (and other) classes.

</p><p>Similar to other modern programming languages ROOM allows <a href="Inheritance_(object-oriented_programming)" title="Inheritance (object-oriented programming)">inheritance</a> of actor classes. It is a single inheritance as an actor class can be derived from another actor class (its <i>base class</i>).

It inherits all features of the base class like ports and actor refs, but also the state machine.

The derived actor class can add further states and transitions to the inherited one.

</p>

<div class="mw-heading mw-heading3"><h3 id="Layering">Layering</h3></div>

<p>A last powerful concept of ROOM is <i>layering</i>. This notion refers to the vertical layers of a software system consisting of services and their clients. ROOM introduces the notions of <i>service access point (SAP)</i> for the client side and <i>service provision point (SPP)</i> for the server side. From the point of view of an actor implementation the SAPs and SPPs work like ports. Like ports they are associated with a protocol. But other than ports they don't have to (and even cannot) be bound explicitly. Rather, an actor is bound to a concrete service by a <i>layer connection</i> and this binding of a service is propagated recursively to all sub actors of this actor.

This concept is very similar to <a href="Dependency_injection" title="Dependency injection">dependency injection</a>.

</p>

<div class="mw-heading mw-heading2"><h2 id="Literature">Literature</h2></div>

<ul><li>Bran Selic, Garth Gullekson, Paul T. Ward: "Real-Time Object-Oriented Modeling", New York, John Wiley & Sons Inc, 1994, <style data-mw-deduplicate="TemplateStyles:r1238218222">

/* start https://en.wikipedia.org/ */

.mw-parser-output cite.citation{font-style:inherit;word-wrap:break-word}.mw-parser-output .citation q{quotes:"\"""\"""'""'"}.mw-parser-output .citation:target{background-color:rgba(0,127,255,0.133)}.mw-parser-output .id-lock-free.id-lock-free a{background:url("./mw/Lock-green.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-limited.id-lock-limited a,.mw-parser-output .id-lock-registration.id-lock-registration a{background:url("./mw/Lock-gray-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .id-lock-subscription.id-lock-subscription a{background:url("./mw/Lock-red-alt-2.svg")right 0.1em center/9px no-repeat}.mw-parser-output .cs1-ws-icon a{background:url("./mw/Wikisource-logo.svg")right 0.1em center/12px no-repeat}body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-free a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-limited a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-registration a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .id-lock-subscription a,body:not(.skin-timeless):not(.skin-minerva) .mw-parser-output .cs1-ws-icon a{background-size:contain;padding:0 1em 0 0}.mw-parser-output .cs1-code{color:inherit;background:inherit;border:none;padding:inherit}.mw-parser-output .cs1-hidden-error{display:none;color:var(--color-error,#d33)}.mw-parser-output .cs1-visible-error{color:var(--color-error,#d33)}.mw-parser-output .cs1-maint{display:none;color:#085;margin-left:0.3em}.mw-parser-output .cs1-kern-left{padding-left:0.2em}.mw-parser-output .cs1-kern-right{padding-right:0.2em}.mw-parser-output .citation .mw-selflink{font-weight:inherit}@media screen{.mw-parser-output .cs1-format{font-size:95%}html.skin-theme-clientpref-night .mw-parser-output .cs1-maint{color:#18911f}}@media screen and (prefers-color-scheme:dark){html.skin-theme-clientpref-os .mw-parser-output .cs1-maint{color:#18911f}}

/* end https://en.wikipedia.org/ */

</style><a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-471-59917-3</bdi><sup id="cite_ref-room-book-summary_1-1" class="reference"><a href="#cite_note-room-book-summary-1"><span class="cite-bracket">[</span>1<span class="cite-bracket">]</span></a></sup></li>

<li>New edition: Bran Selic, Garth Gullekson, Paul T. Ward: "Real-Time Object-Oriented Modeling", Hamburg, MBSE4U, 2023, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-3911081016</bdi></li></ul>

<div class="mw-heading mw-heading2"><h2 id="References">References</h2></div>

/* start https://en.wikipedia.org/ */

.mw-parser-output .reflist{margin-bottom:0.5em;list-style-type:decimal}@media screen{.mw-parser-output .reflist{font-size:90%}}.mw-parser-output .reflist .references{font-size:100%;margin-bottom:0;list-style-type:inherit}.mw-parser-output .reflist-columns-2{column-width:30em}.mw-parser-output .reflist-columns-3{column-width:25em}.mw-parser-output .reflist-columns{margin-top:0.3em}.mw-parser-output .reflist-columns ol{margin-top:0}.mw-parser-output .reflist-columns li{page-break-inside:avoid;break-inside:avoid-column}.mw-parser-output .reflist-upper-alpha{list-style-type:upper-alpha}.mw-parser-output .reflist-upper-roman{list-style-type:upper-roman}.mw-parser-output .reflist-lower-alpha{list-style-type:lower-alpha}.mw-parser-output .reflist-lower-greek{list-style-type:lower-greek}.mw-parser-output .reflist-lower-roman{list-style-type:lower-roman}

/* end https://en.wikipedia.org/ */

</style><div class="reflist">

<li id="cite_note-room-book-summary-1"><span class="mw-cite-backlink">^ <a href="#cite_ref-room-book-summary_1-0"><sup><i><b>a</b></i></sup></a> <a href="#cite_ref-room-book-summary_1-1"><sup><i><b>b</b></i></sup></a></span> <span class="reference-text"><a rel="nofollow" class="external text" href="https://www.lehmanns.de/shop/mathematik-informatik/226929-9780471599173-real-time-object-oriented-modeling">Summary of the book "Real-Time Object-Oriented Modeling"</a></span>

</li>

<li id="cite_note-2"><span class="mw-cite-backlink"><b><a href="#cite_ref-2">^</a></b></span> <span class="reference-text"><a rel="nofollow" class="external text" href="http://www.eclipse.org/etrice">eTrice - ROOM Open Source Tool</a></span>

</li>

<li id="cite_note-3"><span class="mw-cite-backlink"><b><a href="#cite_ref-3">^</a></b></span> <span class="reference-text">Bran Selic, Garth Gullekson, Paul T. Ward: "Real-Time Object-Oriented Modeling", New York, John Wiley & Sons Inc, 1994, <a href="ISBN_(identifier)" class="mw-redirect" title="ISBN (identifier)">ISBN</a> <bdi>978-0-471-59917-3</bdi></span>

</li>

</ol></div></div>

<div class="mw-heading mw-heading2"><h2 id="External_links">External links</h2></div>

<ul><li><span class="noviewer" typeof="mw:File"></span> Media related to <a href="https://commons.wikimedia.org/wiki/Category:Real-Time_Object-Oriented_Modeling" class="extiw external" title="commons:Category:Real-Time Object-Oriented Modeling">Real-Time Object-Oriented Modeling</a> at Wikimedia Commons</li></ul></div><div><div class="zim-footer">

This article is issued from <a class="external text" title="Last edited on 2024-05-24" href="https://en.wikipedia.org/wiki/?title=Real-Time_Object-Oriented_Modeling&oldid=1225412955">Wikipedia</a>. The text is available under <a class="external text" href="https://creativecommons.org/licenses/by-sa/4.0/deed.en">Creative Commons Attribution-Share Alike 4.0</a> unless otherwise noted. Additional terms may apply for the media files.

</div>

</div></div>

</div>

</main>

</div>

</body></html>